InfoMagic Standards 1994 January/InfoMagic Standards - January 1994.iso/inet/ietf/ucp/90dec.min

Text File | 1993-02-17 | 8.1 KB | 235 lines

CURRENT_MEETING_REPORT_


Reported by Dave O'Leary/SURAnet

UCP Minutes

We started by discussing the issue of funding for the activity that is
being proposed in the draft RFC. We decided that the focus of the group
should be only on the definition of the inter-NOC protocol and to handle
issues of multi-NOC coordination, with the goal being the tracking of
complaints rather than tracking problems.  Tracking of complaints
provides accountability information for the funding agencies.  We then
read through the current version of the RFC, section by section, and
discussed needed changes:

NSC's:

The issue of NOC certification needs to be clarified, and a mechanism
for maintaining the ``phonebook'' of NSC's must be decided upon,
although these tasks are outside the scope of this document.  It is
clear that certification and an entry in the phonebook are a one-to-one
correspondence.

Clear job descriptions for NSC's, the ``phone book registrar'', etc.,
are needed, but again, should not be part of this document.

Holes in the phonebook are a problem.  We cannot set enforcement
policies for implementation of the ideas proposed in this document, but
with an incomplete phonebook there may be situations where a ticket is
opened but the entity responsible for fixing the problem is not a
registered NSC and does not/cannot accept the ticket.

Because of these potential holes in the book, particular organizations
are very exposed in the initial system, as they receive many calls, and
are forced to open tickets for each complaint, however there may be no
means for them to resolve the problem or to pass it off to the
responsible entity.

An 800 number NSC Referral service should exist, i.e., ``I have this
problem, who do I call?''  - somebody to look in the phonebook for those
users that don't have a copy.  Those listed in the phonebook must get a
copy of the phone book.  The User Services Working Group Ombudsman may
be able to serve in this role.

We discussed the possibility of ``You aren't our customer'' answers to

                                1






user calls.  The RFC explicitly disallows this, and it was noted that
this restriction could be relaxed in the presence of a national user
ombudsman.

Next we discussed the idea of ``entitlement'' - is every user promised
ideal service?  We concluded that every user has a right to be made
aware of and expect the level of service he is willing to subscribe to.
It was noted that there are some fundamental problems from expectations
of those people who are not actually directly paying for any service,
i.e., a graduate student at a large university doesn't have too much say
as to the university network connection purchasing decisions.

It was decided that an NSC can refer a user to another ticket and refer
the user to the resolution of that ticket, i.e., clustering of several
user complaints under one actual set of ticket transactions.

We then discussed mechanisms for sharing internal ticket information
between NOCs.  Use of a common archiving mail list and the Internet
Rover were proposed as two possible solutions.  Vikas, Dale Johnson, Tim
Salo, Tom Easterday, Dan Long and Dave O'Leary volunteered to start work
on this via a mailing list.

Ticket Processing

It was decided that a NOC could refer a user after it had transferred
responsibility for a ticket, i.e., ``We don't have information about
that ticket anymore, please call Other NSC at 555-1234''.

We discussed problems with unregistered NSC's, particularly complaints
that are caused by software vendor's bugs.  We discussed our role as an
enforcement agent with software vendors, i.e., tracking the number of
vendor X problems that are currently holding open tickets in the system.

Ticket Support Centers

We decided that although the three functions are essentially autonomous,
they will probably reside within the same entity, although they do not
have to.

Dialogs

Multiple User dialogs can map into one Operations dialog, and multiple
Operations dialogs can map into one Engineering dialog.  Meta dialogs
can be associated anywhere into the hierarchy.  The goal of the system
is closure with the user, not closure of operational problems.  It was
noted that ``dead'' tickets could exist, where nobody really cares about

                                2






the resolution, and that a mechanism for tracking chronic problems is
important.  Explicit closure with the user is required, unless the user
waives the right to this explicit closure.

Individual NOC ticket design is not within the scope of the group, and
it was recognized that significant post-processing of tickets will have
to occur in many cases.  We started to look at individual problems and
how a typical ticket would be tracked through this system.  It was
decided that it is okay to tell the user the status of engineering
problems.

We discussed the case of unreasonable user demands - those who are never
satisfied and those who generate many repetitive queries.

The problems that we are trying to solve with the system:


  1. Complaints that are dropped between NOCs.
  2. NOCs that ``lose'' tickets - i.e., quality control on other NOCs.
     - expected level of service is an issue here.
  3. Communication on complaints for knowledge of operational and
     engineering situations.
  4. Statistics on complaints.
  5. Accountability


A different agenda is being addressed by each of the four dialogs, so
the ticketing system must address these four issues.  Individual tickets
may not have discussion in each of the four dialogs.

The introduction to the dialog section should preclude the possibility
of separation of dialogs, i.e., each discussion should be taken in the
context in which it was generated.

Regarding the final status of tickets, it was re-emphasized that tickets
are closed in the User dialog.  Engineering problems are resolved by the
responsible NSC, possibly at a different time from the closure with the
user.  Tickets can be closed with unhappy users, i.e., if an engineering
problem exists with no solution in the foreseeable future.  A question
is how to measure the relative satisfaction before and after the
problem.

Access to Tickets

An NSC can access any ticket in which it is referenced.  Unregistered
entities (i.e., other NOCs) can also access tickets in which they are

                                3






referenced.  It may be appropriate to provide the user more data than is
formally required.

Ticket Tracking System

It Holds:


   o Ticket Numbers
   o Ticket Status (for each dialog)
   o Parties Involved with Ticket
   o A Recent Copy of the Ticket (much discussion was generated)


Privacy Issues:


   o What do the funding agencies think about this?
   o What about disinterested parties with complaints from users?
   o What about the persons involved?


At the end, Matt volunteered to work on the introduction to the document
to clarify the focus in two ways:


  1. It is specifically addressing user complaints.
  2. It is addressing inter-NOC problem resolution.


Following the group meetings, a document editing session was held with
Matt Mathis, Dan Long, Gene Hastings, and Dave O'Leary.  A new draft
will be available soon and inserted into the informational
internet-drafts track.

Attendees

Vikas Aggarwal          [e-mail]
Ronald Broersma         [e-mail]
Robert Collet  /pn=robert.d.collet/o=us.sprint/admd=telemail/c=us/@sprint.com
Tom Easterday           [e-mail]
Jeff Forys              [e-mail]
Vince Fuller            [e-mail]
Jack Hahn               [e-mail]
Eugene Hastings         [e-mail]
Dale Johnson            [e-mail]

                                4






Dan Jordt               [e-mail]
Darren Kinley           [e-mail]
Walter Lazear           [e-mail]
Daniel Long             [e-mail]
Matt Mathis             [e-mail]
Judy Messing            [e-mail]
Donald Morris           [e-mail]
David O'Leary           [e-mail]
Mark Oros               [e-mail]
Timothy Salo            [e-mail]
Tom Sandoski            [e-mail]
Kannan Varadhan         [e-mail]



                                5